Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Chrome Bug Google Security

Severe Chrome Bug Allowed Arbitrary Code Execution (talosintel.com) 85

Posted by EditorDavid from the browser-bugs dept.
An anonymous reader quotes an article from Softpedia: Google has recently patched a high severity security bug in the Chrome browser that allowed crooks to send malicious code to your browser and take over your entire system... Cisco's Aleksandar Nikolic was the researcher that discovered and reported the issue to Google, who even awarded him $3,000 for his efforts.
Chrome's built-in PDF reader PDFium used an OpenJPEG library to parse JPEG2000 files, and in Chrome it was lacking a crucial heap overflow check, according to a post on the Talos security blog. "By simply viewing a PDF document that includes an embedded jpeg2000 image, the attacker can achieve arbitrary code execution on the victim's system."
This discussion has been archived. No new comments can be posted.

Severe Chrome Bug Allowed Arbitrary Code Execution More

Severe Chrome Bug Allowed Arbitrary Code Execution

Comments Filter:

  • Critical bug and award (Score:5, Insightful)

    by hcs_$reboot ( 1536101 ) on Sunday June 12, 2016 @10:36PM (#52303011)
    While it's good that Google rewards people who help make Chrome and the web more secure, $3,000 sounds not enough for such a critical bug.

    • Get rid of the frigging embedded PDF viewer! (Score:5, Interesting)

      by Anonymous Coward on Sunday June 12, 2016 @10:47PM (#52303047)

      The real fix in my opinion is to get rid of the goddamn built in PDF viewers that now bloat browsers like Chrome and Firefox. Clearly they can be abused, like in this case. But in addition to that they just piss me off to no end. In the rare cases when I have to view a PDF, I typically want to use a real PDF viewer. I don't want to use the ones built into the browsers because they usually misrender the PDF in some way! Yeah, I probably could find some way to disable it, but I shouldn't have to. A web browser shouldn't come with a fucking PDF viewer built in!

      • Re: (Score:1)

        by Yvan256 ( 722131 )

        On OS X (macOS), the OS itself can display PDFs. Having a PDF viewer built-in browsers is useless.

      • Re: (Score:1)

        by Anonymous Coward

        Well that's your opinion, I haven't had to install that pain in the arse adobe reader for many years thanks to built-in PDF viewers, I welcome them. One less piece of software consumers have to worry about updating, meaning one less service running on your system constantly running in the background calling back home.

        • There are plenty of free PDF readers out there besides acrobat. One I have used at work is Sumatra PDF [github.com].

        • Re: (Score:2)

          by caseih ( 160668 )

          Chrome is becoming a lot like emacs. It'd be a fine operating system if it just had a decent web browser.

      • Re:Get rid of the frigging embedded PDF viewer! (Score:4, Insightful)

        by Daltorak ( 122403 ) on Monday June 13, 2016 @12:07AM (#52303401)

        The real fix in my opinion is to get rid of the goddamn built in PDF viewers that now bloat browsers like Chrome and Firefox. Clearly they can be abused, like in this case. But in addition to that they just piss me off to no end. In the rare cases when I have to view a PDF, I typically want to use a real PDF viewer. I don't want to use the ones built into the browsers because they usually misrender the PDF in some way! Yeah, I probably could find some way to disable it, but I shouldn't have to. A web browser shouldn't come with a fucking PDF viewer built in!

        Your argument rings pretty hollow considering that the vulnerability has nothing to do with the PDF format itself, or the fact that browsers can render them. The bug was with the PDF viewer's interaction with a third-party JPEG viewer library. In either case, you have to get a user to open the PDF file.... it wouldn't have mattered whether it's baked into a browser or a standalone program.

        The logical continuation of your argument would be to assert that browsers also shouldn't include audio/video codecs because they're also "bloat" that could compromise the system. If you don't want PDF in your browser, you shouldn't want VP9 or MP3 either.

        • Re:Get rid of the frigging embedded PDF viewer! (Score:5, Insightful)

          by mlts ( 1038732 ) on Monday June 13, 2016 @12:20AM (#52303443)

          What we need is almost hypervisor level separation of the browser (and its add-ons) from everything else. This way, if something malicious gets into the browser's context, it couldn't get into the filesystem or memory space of the actual desktop. The closest to this is Qubes OS, or running the browser on a VM under a tier 2 hypervisor (or a tier 1, if you have a fast LAN connection and a decent remote desktop program.) Sandboxing is also an idea, like sandboxIE, but the best thing is complete isolation, OS kernel, filesystem, the works. This also allows an outside program to eyeball the browser's RAM space for malicious software signatures and put a kibosh on would-be rootkits.

          • Re: (Score:1)

            by Anonymous Coward

            FreeBSD already has that, and Chromium on FreeBSD already makes use of it. With Capsicum (capabilities based security) the browser can only open files in directories it opened before entering capabilities mode, and likewise with network connections.

            This is already a solved problem, people just need to use the solutions that are out there. Pledge from OpenBSD would go a long way to mitigating these issues too. Linux has seccomp2 and various other capabilities based security models, but the problem there is t

        • The real fix in my opinion is to get rid of the goddamn built in PDF viewers that now bloat browsers like Chrome and Firefox. Clearly they can be abused, like in this case. But in addition to that they just piss me off to no end. In the rare cases when I have to view a PDF, I typically want to use a real PDF viewer. I don't want to use the ones built into the browsers because they usually misrender the PDF in some way! Yeah, I probably could find some way to disable it, but I shouldn't have to. A web browser shouldn't come with a fucking PDF viewer built in!

          Your argument rings pretty hollow considering that the vulnerability has nothing to do with the PDF format itself, or the fact that browsers can render them. The bug was with the PDF viewer's interaction with a third-party JPEG viewer library. In either case, you have to get a user to open the PDF file.... it wouldn't have mattered whether it's baked into a browser or a standalone program.

          The logical continuation of your argument would be to assert that browsers also shouldn't include audio/video codecs because they're also "bloat" that could compromise the system. If you don't want PDF in your browser, you shouldn't want VP9 or MP3 either.

          That logical continuation of the argument is CORRECT.
          Browsers should defer to the OS for non web data. Put shit in <media> and let the browser call upon the OS to DO SOMETHING with the media, and fail back to a simple download link.

          • Browsers should defer to the OS for non web data. Put shit in and let the browser call upon the OS to DO SOMETHING with the media

            Not every operating system ships with support for every codec known to man. For example, OS X ships without the WebM codec stack (Matroska container, VP8 and VP9 video codecs, and Vorbis and Opus audio codecs), instead relying on the patented, royalty-bearing MPEG-4 stack. So does Windows prior to Windows 10.* Your suggestion would bring us back to the days of having to install OS-level "codec packs", as well as the trojans that masquerade as codec packs. These trojans used to be fake antivirus; nowadays, t

      • Re:Get rid of the frigging embedded PDF viewer! (Score:5, Informative)

        by DrXym ( 126579 ) on Monday June 13, 2016 @03:27AM (#52304209)
        Chrome and Firefox render PDFs in different ways.

        Firefox implements PDF.js [github.com]. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo [github.io] of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.

        Chrome uses plugin called PDFium [googlesource.com]. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.

        Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.

        • to be clear: this was not a bug in the third party code. The vulnerability was *created* by Google's programmers removing an assert() from the library. The fix was for them to replace the assert() with an if() statement. Conceptually, this is similar to the debian ssh bug where the debian maintainer of openssh removed nearly all entropy by "fixing" the code so that it wouldn't generate a compile-time warning.

          Don't go blaming third parties when its the integrator's fault.

      • But... But... Browser plugins are evil, and we must do away with them and move everything into the browser itself to be safe! The Internets keep telling me so.

    • While it's good that Google rewards people who help make Chrome and the web more secure, $3,000 sounds not enough for such a critical bug.

      3K is super low for a finding like this. He could have taken it to other well heeled folks and made 30x this amount.

  • Wait... (Score:5, Informative)

    by AmiMoJo ( 196126 ) on Sunday June 12, 2016 @11:18PM (#52303205) Homepage Journal

    It could execute code in the browser tab's process, but that's a long long way from taking over your system. Hence the relatively low bounty, compared to really serious exploits that can break out of the sandbox and bypass OS security.

    • Turns out that wasn't such a clever idea after all. Its the reason I never installed Chrome on any linux box I own.

    • But, you wait ....

      We are moving everything to the cloud.

      The cloud is accessed from browser sessions with current credentials automatically and silently.

      So arbitrary code execution with current user privileges on a browser session is really a serious threat.

  • IE 6 (Score:4, Funny)

    by Billly Gates ( 198444 ) on Monday June 13, 2016 @12:18AM (#52303437) Journal

    I just checked and I am using IE 6 so I should be safe

  • Last year I worked on an old project where we converted old assert macros to ifs precisely because they were #defined out of existence in production code. Stupid fucking things should be banned. This was an embedded system.

    • assert originated when the extra if check was costly, usually in embedded systems. You don't want to do a check when you know 100% sure it is never going to happen. Of course, cpu cycles are not that critical these days in 99.99% or more applications that this style of assert is no longer needed; not only not-needed they are dangerous as seen in this exploit. [of course if you an embedded system like say switches/network processors, where each cycle counts, you may still dont' want to put in unnecessary ch

    • Point was if you are relying on them to prevent bad things from happening, then compile them away for production, you need to build an if around them instead. Hence they only have development value. Hence programmers get lazy using them and never get around to cleaning them up like they are supposed to. To the tune of hundreds of instances in non-trivial code.

      Then you run a code review tool and it points this out.

  • Finding NULL return usage from malloc/calloc is something static-analysis tools (like beefed up lint tools) easily spot. Not sure why they didn't run the source thru' static analysis or marked the flagging as noise. This case is finding the input arg to calloc could be zero and hence can get a NULL return (they say implementation dependent; most cases it's NULL when you ask for zero bytes/items to a calloc library)
  • And this is why having a way to provide software updates to the field without annoying the end user is important.
  • This is why instead of embedding a plugin in the browser for PDFs, Mozilla has created PDF.js [github.com]. It uses HTML5 & JavaScript to render PDFs within the browser's normal sandbox. There's even a Chrome addon [google.com].
  • Is there a link to a demo for this Chrome PDF reader bug?

Slashdot Top Deals

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"

Close